Gestión de requisitos
Introducción
Es inevitable que durante el desarrollo de un proyecto los requisitos sufran algún tipo de evolución. El desarrollo del software se ve influido por factores como los objetivos de negocio, la opinión de los stakeholders, la evolución de otros sistemas relacionados... Además, a medida que se desarrollan los requisitos, se obtiene una mejor comprensión de las necesidades del usuario, lo cual puede hacer que se modifiquen algunos aspectos de la especificación.
La gestión de requisitos es el proceso de comprender y controlar los cambios en los requisitos del sistema.
La volatilidad de los requisitos
Los requisitos de un sistema software cambian con el tiempo. No solo porque la especificación evoluciona, sino porque pueden aparecer nuevos requisitos, mientras que otros desaparecen.
El ambiente empresarial y tecnológico puede cambiar durante el desarrollo del proyecto y tras la puesta en funcionamiento del producto (Objetivos, legislaciones, necesidades...).
Los clientes y usuarios no siempre coinciden, teniendo punto de vista diferentes y teniendo más peso la opinión del cliente, pues es quien nos paga.
Los grandes sistemas tienen comunidades de usuarios muy amplias con intereses y perfiles muy diversos. Lo que satisface al público potencial en un momento dado puede quedar obsoleto a medida que los usuarios cambian sus hábitos y preferencias.
La comprensión del producto también evoluciona. A medida que el analista y otros stakeholders profundizan en el descubrimiento de las necesidades y la propuesta de soluciones, los requisitos también evolucionan.
Clasificación de requisitos según su evolución
Requisitos duraderos: son relativamente estables y están muy relacionados con el dominio de aplicación.
Requisitos volátiles: son aquellos susceptibles de cambiar durante el desarrollo del sistema o después de su puesta en operación.
Podemos clasificarlos en cuatro subcategorías:
Mutables o cambiantes: evolucionan como consecuencia de cambios en el entorno de operación.
Emergentes: evolucionan como consecuencia de una mejor comprensión del sistema a medida que se desarrolla.
Consecuentes: derivados de la interacción del sistema con su entorno.
Compatibilidad: cuando el sistema depende de otros sistemas, cuando estos sistemas cambian hay que adaptar los requisitos a estos cambios.
Requisitos básicos o de referencia
La ingeniería de requisitos se puede dividir en dos grandes categorías de actividades:
Desarrollo de los requisitos: elicitación, análisis, documentación y validación.
Gestión de los requisitos:
En sentido amplio: Actividad transversal.
En sentido restringido: Monitorización de los cambios en los requisitos básicos.
Los requisitos básicos son un conjunto de requisitos revisado y acordado, que generalmente define los contenidos de una release específica, una iteración, o todo el proyecto.
Proceso de gestión de requisitos
La gestión de requisitos incluye todas las actividades relacionadas con mantener la integridad, precisión, y actualidad de los requisitos a lo largo del proyecto.
Cada organización debe adaptar este proceso a sus necesidades.
Atributos de los requisitos
Los atributos de los requisitos completan la información del requisitos, ayudando a favorecer la trazabilidad y el mantenimiento de la especificación.
Fecha de creación.
ID y nombre.
Versión actual (e historial de modificaciones).
Autor, fuente, motivación del requisito, stakeholders involucrados...
Prioridad.
Estado (aprobado, implementado, validado...).
Número de release para la cuál está planificado.
Método de validación o criterios de aceptación.
El empleo de muchos atributos también puede resultar contraproducente, pues cuantos más hay, más se complica la gestión.
Control de versiones de requisitos
Es fundamental emplear un identificador único para cada requisito y versión.
El histórico de cambios debe mostrar:
El cambio realizado.
La fecha del cambio.
El autor del cambio.
La razón del cambio.
Lo ideal es utilizar una herramienta específica para la gestión de requisitos (Git, SVN...) o emplear documentos de texto con control de cambios.
Control de cambios en los requisitos
Los cambios deben ser contemplados de manera cuidadosa durante la gestión de requisitos.
Seguimiento de estado
El estado de un requisito (status), permite el seguimiento del estado del requisito.
| Status | Definición |
|---|---|
| Propuesto (porposed) | Se ha solicitado el requisito por una fuente autorizada. |
| En progreso (in progress) | Un analista está trabajando en su definición. |
| En borrador (rafted) | Existe una versión escrita inicial del requisito. |
| Aprobado (approved) | Se ha analizado el requisito evaluando su impacto en el proyecto, y se ha asignado a una release. |
| Implementado (implemented) | El código que implementa el requisito está escrito y pasa las pruebas unitarias. Este código está listo para proseguir con otras fases de pruebas. |
| Verificado (verified) | La implementación del requisito satisface los criterios de aceptación. Se confirma su correcta implementación y completa su implementación. |
| Diferido o pospuesto (deferred) | Son requisitos aprobados que se reasignan a una release posterior. |
| Eliminado (deleted) | Son requisitos aprobados que se eliminan de una release. Hay que incluir información de quién y por qué tomó la decisión. |
| Rechazado (rejected) | Son requisitos propuestos que nunca fueron aprobados, y por tanto nunca serán implementados. Hay que incluir información de quién y por qué tomó la decisión. |
| Diseñado (designed) | Los elementos de diseño relacionados con el requisito están diseñados y aprobados. |
| Entregado (delivered) | El software que contiene este requisito está ya en manos del usuario, quien tal vez deba realizar pruebas de aceptación o pruebas beta. |
Trazabilidad
La trazabilidad permite relacionar cada requisito con el resto de la especificación.
Ventajas
Mejora la verificabilidad, permitiendo comprobar que un requisito y todas sus dependencias han sido implementadas.
Mejora el análisis de impacto, permitiendo evaluar el alcance del cambio.
Mejora la reutilización, permitiendo analizar grupos de requisitos que pueden trasladarse de un proyecto a otro.
Mejora el mantenimiento, ayudando a detectar la raíz de un problema y prevenir otros relacionados.
Para la documentación de las relaciones entre los elementos de la especificación es habitual el empleo de matrices de trazabilidad o grafos de trazabilidad.
